front_end/src/app/(main)/questions/components/forecaster_counter.tsx (1)

65-70: 💤 Low value

strong passthrough silently strips RichText's default strong renderer when boldCount is false.

The explicit strong key at line 65 overrides whatever handler ...tags (spread from RichText) injected for <strong>. When boldCount is false, raw chunks are returned unwrapped, discarding the default rendering contract from RichText. If RichText's strong tag ever applies its own styling (e.g. font-semibold), the non-bold path will silently drop it.

If the intent is strictly "bold only when boldCount=true, otherwise no emphasis at all", this is correct. Otherwise, consider falling back to tags.strong:

♻️ Proposed defensive passthrough

-                strong: (chunks) =>
-                  boldCount ? (
-                    <span className="font-bold">{chunks}</span>
-                  ) : (
-                    chunks
-                  ),
+                strong: boldCount
+                  ? (chunks) => <span className="font-bold">{chunks}</span>
+                  : tags.strong,

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@front_end/src/app/`(main)/questions/components/forecaster_counter.tsx around
lines 65 - 70, The current custom `strong` renderer in the forecaster_counter
component overrides RichText's default handler and returns raw `chunks` when
`boldCount` is false, dropping any default styling; update the `strong`
passthrough so that when `boldCount` is true it wraps with your bold markup,
otherwise it calls and returns the original `tags.strong` handler (or the
default renderer) so RichText's intended styling/behavior is preserved; look for
the `strong: (chunks) =>` entry near the `...tags` spread and change the false
branch to delegate to `tags.strong` (or equivalent) instead of returning raw
`chunks`.

posts/views.py (1)

567-583: with_cp=True on the similar-posts endpoint conflicts with its own "don't overload Redis" comment

The endpoint previously had a lighter serialization call specifically to avoid Redis pressure. The new with_cp=True triggers prefetch_questions_scores() for every similar-post lookup. group_cutoff=1 helps, but the change is still a net increase. Consider whether CP data is strictly required here for the sidebar design, or whether a lighter approach (e.g., skipping with_cp, or caching the response at the view level) would be sufficient.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@posts/views.py` around lines 567 - 583, The similar-posts view
post_similar_posts_api_view currently calls serialize_post_many(...,
with_cp=True) which forces prefetch_questions_scores and increases Redis load;
change this to a lighter serialization by removing or setting with_cp=False (or
add a flag to only include CP when explicitly requested) so serialize_post_many
is called without triggering prefetch_questions_scores, or alternatively
implement view-level caching around the serialized result in
post_similar_posts_api_view to avoid repeated CP prefetches; update the call
site (serialize_post_many in post_similar_posts_api_view) and any tests that
assume CP fields are present.

front_end/src/app/(main)/questions/[id]/components/question_page_shell/tabs/comments.tsx (1)

12-16: ⚖️ Poor tradeoff

Consider adding a flat/no-container-styles prop to CommentFeed instead of the !important selector chain.

The wrapper div's [&>section]:!* overrides are fragile — they silently break if CommentFeed's internal element ever changes from <section> to something else. A noContainerStyles (or similar) prop on CommentFeed would be more resilient and expressive.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@front_end/src/app/`(main)/questions/[id]/components/question_page_shell/tabs/comments.tsx
around lines 12 - 16, The wrapper uses fragile tailwind child selector overrides
on <section> to remove container styles; instead add a boolean prop (e.g.,
noContainerStyles or flat) to the CommentFeed component and have CommentFeed
apply the containerless classes internally when that prop is true. Update the
CommentsTab component to pass noContainerStyles (or flat) to CommentFeed and
remove the `[&>section]:!*` overrides so the styling control is explicit and
resilient to internal markup changes.

front_end/src/app/(main)/questions/[id]/components/question_page_shell/meta_row.tsx (1)

49-54: 💤 Low value

Initial render shows default chip count (2) regardless of container width.

When width === 0 (before the resize observer fires on first paint), maxVisibleChips evaluates to 2 and compactCounters to false. This is fine as a safe default, but it will cause a visible layout shift on narrow containers. Consider initializing useContainerSize or the width thresholds more conservatively (e.g., default maxVisibleChips to 1) if the layout shift is noticeable in practice.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@front_end/src/app/`(main)/questions/[id]/components/question_page_shell/meta_row.tsx
around lines 49 - 54, The initial render uses width === 0 which causes
maxVisibleChips to default to 2 and compactCounters to false, creating a layout
shift; update the logic in the component around compactCounters and
maxVisibleChips (the variables computed from width, and where useContainerSize
provides width) to treat width <= 0 as an unknown/initial state and return
conservative defaults (e.g., set maxVisibleChips = 1 and compactCounters = true
when width <= 0) so the first paint matches narrow-container behavior until the
resize observer fires.

front_end/src/stories/question_page/date_question/date_question.stories.tsx (1)

76-76: 💤 Low value

buildKey can return an empty string.

When no transform rules apply, appliedKeys is empty and this returns "" as the key, which can be problematic for React reconciliation. Other migrated stories in this PR (e.g., binary_group_timeline.stories.tsx) use a "default" fallback. Consider aligning for consistency:

Proposed alignment

-  buildKey: (_, appliedKeys) => `${appliedKeys.join("-")}`,
+  buildKey: (_, appliedKeys) =>
+    appliedKeys.length > 0 ? appliedKeys.join("-") : "default",

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@front_end/src/stories/question_page/date_question/date_question.stories.tsx`
at line 76, The buildKey function currently returns an empty string when no
transform rules apply because appliedKeys is empty; update the buildKey
implementation (the buildKey property in date_question.stories.tsx) to return a
non-empty fallback (e.g., "default") when appliedKeys.length === 0 so React
reconciliation is stable and consistent with other stories like
binary_group_timeline.stories.tsx.

front_end/src/app/(main)/questions/[id]/components/sidebar/similar_questions/similar_question_card.tsx (1)

109-136: 💤 Low value

Forecaster footer chip styling looks slightly inconsistent.

Three sibling chips share the same row but use different backgrounds/padding:

• Comment chip (Line 112): rounded-xs bg-gray-200 px-1.5
• Status icon container (Line 119): rounded-xs bg-gray-200 px-1 (narrower padding)
• Forecasters chip (Line 128): no background, no rounding (text-xs leading-4 text-gray-700 only)

If this is the intended design (e.g., status badge gets tighter padding, forecasters count is unboxed), feel free to ignore. Otherwise consider unifying them, since visually adjacent counters typically benefit from a single chip style.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@front_end/src/app/`(main)/questions/[id]/components/sidebar/similar_questions/similar_question_card.tsx
around lines 109 - 136, The three adjacent footer chips in SimilarQuestionCard
(rendered when isForecaster) use inconsistent classes: the comment span, the
PostStatusIcon container, and the forecasters span; unify their appearance by
applying a consistent chip class set (e.g., "flex h-6 items-center gap-1
rounded-xs bg-gray-200 px-1.5 text-xs leading-4 text-gray-700
dark:bg-gray-200-dark dark:text-gray-700-dark") to the comment span, the wrapper
div around PostStatusIcon, and the forecasters span so PostVoter, PostStatusIcon
wrapper, and the forecasters count (forecastersFormatted) all share the same
background, padding, rounding and text styles.

front_end/src/app/(main)/questions/[id]/components/question_page_shell/title_row.tsx (1)

42-55: 💤 Low value

Remove ineffective order-* utilities from single-child flex container.

The div at line 43 is the only child within its flex parent (line 42), so order-1 lg:order-0 are dead code—CSS order only reorders flex items relative to siblings. Additionally, lg:order-0 is not part of Tailwind's default order scale (which supports order-1–order-12, order-first, order-last, order-none) and the project config does not extend this scale, so lg:order-0 silently produces no CSS.

If reordering the title row relative to the desktop CP status block at line 56 was intended, these utilities should be applied to siblings at the parent level (line 38), not nested inside line 42.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@front_end/src/app/`(main)/questions/[id]/components/question_page_shell/title_row.tsx
around lines 42 - 55, The order utilities on the inner container (the div with
class "lg:order-0 order-1 flex items-center") are ineffective because its parent
(the div with class "flex flex-1 flex-col") has only that single child; remove
the `order-1` and `lg:order-0` classes from that inner div. If you intended to
reorder the title vs. the desktop CP status (components QuestionTitle and
QuestionHeaderCPStatus), move the order classes to the relevant sibling
containers at the parent level so the `order-*` utilities affect sibling
ordering instead of applying them on this single-child element.

front_end/src/app/(main)/questions/[id]/components/question_page_shell/index.tsx (1)

77-84: ⚡ Quick win

Duplicate CommunityDisclaimer block — consider extracting to a helper

The exact same CommunityDisclaimer snippet appears in both ForecasterShell (lines 77-84) and ConsumerShell (lines 175-182). A small helper or shared fragment would remove the duplication.

♻️ Proposed refactor

+const CommunityBanner: FC<{ post: PostWithForecasts }> = ({ post }) =>
+  post.projects?.default_project?.type === TournamentType.Community ? (
+    <CommunityDisclaimer
+      project={post.projects.default_project}
+      variant="standalone"
+      className="block sm:hidden"
+    />
+  ) : null;

 // ForecasterShell
-          {postData.projects?.default_project?.type ===
-            TournamentType.Community && (
-            <CommunityDisclaimer
-              project={postData.projects.default_project}
-              variant="standalone"
-              className="block sm:hidden"
-            />
-          )}
+          <CommunityBanner post={postData} />

 // ConsumerShell
-        {postData.projects?.default_project?.type ===
-          TournamentType.Community && (
-          <CommunityDisclaimer
-            project={postData.projects.default_project}
-            variant="standalone"
-            className="block sm:hidden"
-          />
-        )}
+        <CommunityBanner post={postData} />

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@front_end/src/app/`(main)/questions/[id]/components/question_page_shell/index.tsx
around lines 77 - 84, Duplicate JSX rendering of CommunityDisclaimer exists in
ForecasterShell and ConsumerShell; extract it into a small helper/component
(e.g., renderCommunityDisclaimer or CommunityDisclaimerFragment) and replace
both inline blocks with a single call. The helper should accept the same props
used now (project: postData.projects.default_project, variant: "standalone",
className: "block sm:hidden") and perform the conditional check
postData.projects?.default_project?.type === TournamentType.Community before
returning <CommunityDisclaimer /> so both ForecasterShell and ConsumerShell
simply invoke the helper to remove duplication.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes